**what this does**
Adds a packaging-time filter, `dd_pkg_files_stripped` (in
`bazel/rules/dd_packaging/dd_pkg_strip_transform.bzl`), that replaces plain
`pkg_files` calls for shipped binaries. It strips object files as they're
collected into a package and splits the removed debug info into a parallel
`name + "_debug"` sibling target, without requiring any cooperation from the
binary's own build rule -- it works directly against prebuilt-file-backed
targets like `@agent_binary//:agent`, which is this design's main advantage
over the alternative provider/rule-based approach considered in the same
design doc (Plan A, implemented separately).

A single `_dd_strip_split` action runs strip/objcopy/dsymutil once per file
and declares both the "stripped" and "debug" outputs at once; the public
`dd_pkg_strip_transform` rule only projects one half of that shared result,
so building both the normal package and its debug sibling never doubles the
work. File-type detection (ELF/Mach-O/PE) happens at action-execution time in
a new Python driver (`dd_strip_driver.py`), since Starlark can't inspect file
contents during analysis; the Starlark side only applies a cheap
extension/mode-bit heuristic to skip spawning actions for obviously
non-binary files.

Tool paths come from a new `//bazel/toolchains/dd_strip` toolchain: Linux and
Windows source `strip`/`objcopy` off the existing `cc_toolchain`; macOS
hardcodes `/usr/bin/strip` and `/usr/bin/dsymutil` (modeled after
`//bazel/rules/rewrite_rpath`'s hardcoded-path pattern rather than
`//bazel/toolchains/codesign`'s auto-detecting repository_rule, since that
pattern generates a `config_setting` per tool and new config_settings need
separate design review).

Platform semantics match `omnibus-ruby/lib/omnibus/stripper.rb`: Linux does
the 3-step objcopy --only-keep-debug / strip / objcopy --add-gnu-debuglink;
macOS runs `strip -x` plus `dsymutil` into a `.dSYM` bundle; Windows ships a
`strip`'d binary alongside the unstripped original (mingw's toolchain has no
`objcopy`, so there's no split-DWARF story there, matching the existing
`windows_symbol_stripping_file` behavior).

Wired into `packages/agent/product/BUILD.bazel` (the four `dda_built_*_binary`
targets, plus a new `all_files_debug` pkg_filegroup) and
`packages/installer/windows/BUILD.bazel` (`installer_binary` plus a new
`installer_components_debug`). Removed the one-shot
`-Cstrip=symbols` rustc flag from `bazel/configs/system_probe_lite.bazelrc`,
which used to destroy debug info before packaging ever saw it. Updated
`packages/AGENTS.md` and `packages/installer/MIGRATION_PLAN.md` to reflect
that symbol stripping is now migrated.

**testing**
Built and inspected output on macOS (arm64) at each stage:
- A throwaway target wrapping `//cmd/loader:loader` confirmed both the
  "stripped" and "debug_only" modes produce sane output: `strip -x` removed
  local symbols, `dsymutil` produced a `.dSYM` bundle with a DWARF resource,
  and building both mode targets together registered the `DdStripSplit`
  action exactly once (verified in the verbose build log).
- `bazel build //packages/agent/product:all_files //packages/agent/product:all_files_debug`
  and `//packages/installer/windows:whole_distro_tar //packages/installer/windows:installer_components_debug`
  succeed against the real prebuilt targets (`@agent_binary`,
  `@trace_agent_binary`, `@process_agent_binary`,
  `@privateactionrunner_binary`, `@installer_binary`).
- Along the way, fixed two real bugs surfaced by this: `Args.add()` can't
  take a directory (needed `.path` for the `.dSYM` output), and the
  passthrough path crashed when the declared debug output was a directory
  but the driver couldn't recognize the input's format (hit when packaging a
  Linux ELF prebuilt from a macOS host, since the macOS toolchain has no
  objcopy -- this is a local-only condition, not a bug in the Linux path
  itself).
- `bazel test //bazel/rules/dd_packaging:_dd_packaging_tests` (the existing
  suite) still passes -- no regression in the unrelated packaging rules this
  shares a package with.
- Could NOT verify on this machine: the actual Linux ELF split (no Linux
  sandbox/CI available locally -- the `@trace_agent_binary` prebuilt is a
  real Linux ELF, but macOS's `dd_strip` toolchain has no `objcopy`, so it
  fell through to passthrough rather than exercising `_strip_elf`), and
  whether the produced `.dSYM`/`.debug` artifacts are actually useful to a
  debugger (no symbolication round-trip was attempted).
- No unit tests were added for `dd_pkg_strip_transform`/`_dd_strip_split`
  themselves (analysistest-style, like `dd_packaging_test.bzl`) -- only
  manual `bazel build` + filesystem inspection.

**next steps**
- The Linux objcopy path needs validation in CI or a Linux sandbox before
  this can be trusted end-to-end.
- The macOS `dSYM`-splitting approach hasn't been reviewed by the build
  team; `strip -x` semantics (keeps global symbols) match omnibus but
  deserve a second look.
- Whatever builds `bin/agent/agent` and friends outside Bazel (dda/omnibus)
  must also stop pre-stripping, or there will be no debug info left for this
  filter to split off -- that's a separate, out-of-scope dependency for this
  PR (the Rust/system-probe-lite case is fixed here; the Go/dda case is not).
- Plan A (implemented separately, in parallel) builds its own independent
  copy of the same toolchain shape under `//bazel/toolchains/dd_strip` by
  design -- deduplicating the two toolchains is a deliberate follow-up, not
  done here.